Skip to content

Conversation

Manishearth
Copy link
Member

Progress on #7104. I didn't touch MonthCode yet since it becomes easier after #7105 lands.

@Manishearth Manishearth requested a review from sffc as a code owner October 16, 2025 19:36
@Manishearth Manishearth merged commit 8371b92 into unicode-org:main Oct 16, 2025
30 checks passed
@Manishearth Manishearth deleted the era-bytes branch October 16, 2025 20:38
@robertbastian
Copy link
Member

The conclusion in #7104 included "Clear docs on what those fields represent and how to build them". This PR does not do that, now we have undocumented byte slices on our API.

@Manishearth
Copy link
Member Author

I added "ASCII byte slice" in #7105. I don't know how to document that in a more clear way, I guess I could link to era codes.

@sffc
Copy link
Member

sffc commented Oct 20, 2025

I had envisioned examples about how to either construct month codes using b strings or using .as_bytes(). If we already have these examples, then we don't need to add more.

@Manishearth
Copy link
Member Author

@sffc we do not currently have these examples on DateFields.

Manishearth added a commit that referenced this pull request Oct 20, 2025
Depends on #7115, depends on #7105

Attempt at fixing #7104.

The user experience of the byte slice is a little bit worse if you want
to use MonthCode::new_normal/new_leap since you have to persist those
for a while.

Most people will not be creating them for long, though. In theory we
could produce byte versions of those methods that produce a limited
range of codes. It's more a problem for our tests that need to do things
like "create many codes in a loop".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants